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^ 1 Introduction 
O 

In this work we study the performance of a heterogeneous wireless sensor network which consists of 4 different 
O hardware platforms (TelosB, SunSPOT, Arduino, iSense). These hardware platforms are the most representa- 
O tive ones, as used by the relevant research community. 

All hardware platforms use 802.15.4 compliant radios. Due to partial implementation of the standard, they 
do not communicate out of the box. A first contribution of our work is a careful description of the necessary 

I ^steps to make such a heterogeneous network interoperate. Our software code is available online. 

We deploy a heterogeneous network testbed and conduct a thorough evaluation of the performance. We 
Q examine various network performance metrics (e.g., transmission rate, receiving rate, packet loss, etc.), and 
assess the capabilities of each device and their intercommunication. We used different setups (e.g., distance 
I ^ . between transmitters and receivers, etc.) to better understand the network limitations for each hardware 
platform. 

Out study demonstrates the differences between the hardware platforms. The platform with the larger 
00 transmitting and receiving rate is the iSense. iSense is the only device with 0% packet loss regardless of the 
transmitting device, the distance and the packet size. In contrast to iSense, Arduino is the only device with 
^ packet loss over 50% in large distances, with packet size over 50 bytes. The SunSPOT and TelosB use the 
same hardware. Interestingly, although the SunSPOT has a much more powerfull processor and a lot of more 
^1 memory available, the way Java Virtual Machine operates, limits the overall network performance. Thus the 
TelosB, achieves much higher transmission rates. We also observe that the RSSI provided by each hardware 
platform are totally different and in fact no correlation can be found. This is an alarming observation for 
^ Network Algorithms that rely on RSSI and need to operate in heterogeneous setting. 

'x 

a 2 Hardware Description 

2.1 Arduino Duemilanove with XBee ImW Chip Antenna 



Arduino [T| (figure la) is an open-source electronics prototyping platform. The Arduino Duemilanove is a 
microcontroller board based on the ATmega328. It has 14 digital input/output pins, 6 analog inputs, a 16 
MHz crystal oscillator, a USB connection, a power jack, an ICSP header, and a reset button. The Arduino 
is connected with the XBee [8j Series 1 Chip Antenna. The Xbee module provides IEEE 802.15.4 network 
connectivity to the Arduino. The core libraries of Arduino are written in C and C++ and compiled using 
avr-gcc and AVR Libc. Arduino hardware is programmed using a Wiring [12] based language, similar to C++ 
with some simplifications and modifications, and a Processing [T3] based IDE. Libelium Waspmote [2] has a 
similar microcontroller and a similar radio transmitter to Arduino. 
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2.2 SunSPOT 



SunSPOT [6] (figure lb) is a small, battery-operated device running the Squawk Java Virtual Machine, which 
acts as both an operating system and a software application platform, allowing programming of the devices in 
the Java Micro Edition (J2ME) platform. It uses an 180MHz ARM 9 processor with 512KB of RAM and 4MB 
Flash. An IEEE 802.15.4 compliant CC2420 Chipcon transceiver is used for communication. 



2.3 TelosB mote 



TelosB [7] (figure [Tc]) is 2.4GHz IEEE 802.15.4 compliant and comes with a 10KB RAM module, a 48 kBytes 
program Flash memory and the TI-MSP430 microprocessor, which is running on 4 MHz. TelosB are running 
the TinyOS version 2.1.0 [10] operating system and their software is written in nesC. Prisma Sesnse Quax 
MS-Pro ^Sj is a hardware platform with similar processor to TelosB and the Scatter Web MSB-430 [4J is another 
platform with similar architecture and the same processor but uses a different radio chipset (CC1020) which is 
not 802.15.4 compliant. 




(a) Arduino (b) SunSPOT (c) TelosB 

Figure 1: Hardware Devices 



(d) iSense 



2.4 iSense 

iSense [5j was obtained by Coalesenses GmbH based in Luebeck, Germany. It is comprised by iSense Core 
modules (figure [Td| ) for both Receiving and Transmitting Nodes. The Core module uses IEEE 802.15.4 Zigbee 
compliant radio(JN5139) and has a 32bit RISC Controller running at 16MHz. It features 96kB of RAM abd 
128kB of Serial Flash. The iSense OS and the programming of the devices is in the C++ language. 
The hardware differences are summarized in the following table, Table [T| 





Processor 


MIPS 


RAM 


Flash 


Radio 


Program. Lang. 


Arduino 


ATmega328(16 MHz) 


16 


16 KB 


32 KB 


XBee Series 1 


Wiring (C++) 


SunSPOT 


ARM920T(180 MHz) 


200 


512 KB 


4 MB 


CC2420 


J2ME 


TelosB 


MSP430(16 MHz) 


16 


10 KB 


48 KB 


CC2420 


nesC 


iSense 


JN5139(16 MHz) 


16 


96 KB 


128 KB 


JN5139 


C++ 



Table 1: Comparison of Platforms. 



3 MAC Implementation 

Each of the considered sensor devices is equipped with an IEEE std. 802.15.4 - 2003 [9j compliant radio 
to perform wireless communication. However, each one of them provides only partial implementations of the 
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IEEE 802.15.4, which are not compatible with each other. Therefore the communication between the 4 different 
devices is not possible out of the box. 

IEEE 802.15.4 provides two different addressing modes, the 16-bit addressing and the 64-bit. The SunSPOT 
radio stack supports only the 64-bit addressing mode, while TelosB supports only the 16-bit. Radio stacks of 
XBee and iSense provide both the 64-bit and the 16-bit addressing modes. 

The first step on our Heterogeneous Sensor Network was to set all the devices to the 16-bit addressing 
mode. XBee was set on the 802.15.4 Mac mode with auto-ACKs. We also implemented a new radio stack on 
SunSPOT which supports the 16-bit addressing mode. 

Based on the LowPAN specification, the Sun SPOT library provides routing, meshing and fragmentation 
using the LowPAN, on the network layer. LowPAN adds some extra headers on the 802.15.4 packets. In 
particular, after the 802.15.4 headers, two extra bytes are added by the LowPAN which define whether the 
packet is LowPAN compliant, whether it is fragmented, whether it is meshed etc. 

Our network stack does not support fragmentation and mesh routing. So on each radio stack, two constant 
bytes at the beginning of the payload of each packet had to be added, in order to define that each packet is 
not fragmented or meshed. In this way, the LowPAN on the network layer of the SunSPOT is bypassed and 
the communication between the 4 different sensor nodes is possible. 

The differences of the 4 platforms are summarized in the following table, table [2] 



Platform 


Max Payload Size 


Addressing Mode 
16-bit 64-bit 


Incompatibilities 


Arduino XBee 


100 bytes 


YES 


YES 


Extra Headers (MaxStream Headers) 


SunSPOT 


113 bytes 


NO 


YES 


Extra Headers (LowPan) 


TelosB 


128 bytes 


YES 


NO 


Auto Ack is Disabled 


iSense 


116 bytes 


YES 


YES 





Table 2: Comparison of Platforms. 



The customized radio stack for SunSPOT was implemented in Java J2ME, while the library, which enables 
the communication on iSense and Arduino, was implemented in C++. TelosB motes were running the TinyOS 
version 2.1.0 [10], so the component for the Telosb was written in nesC. 

A similar work, is the TinySPOTComm [TT] library. In contrast to our work, TinySPOTComm enables the 
communication between only 2 devices, SunSPOT and TelosB. 

4 Experimental Setup 

The setup consists of two different group of sensor nodes: the Receiving Nodes and Transmitting Nodes. Each 
of these groups consists of 4 nodes, one Arduino, one SunSPOT, one TelosB and one iSense. The layout of the 
experiment can be seen in the following figure [2j 

All nodes were positioned at a height of 60cm from the ground to avoid ground reflections of the wireless 
signal. All four Receiving Nodes had the same orientation, pointing their antennas to the Transmitting Nodes 
(in contrast to figure [2]). We use 3 different setups regarding the distance between the Transmitting nodes and 
the Receiving Nodes. The Transmitting Nodes were placed in 3 different distances from the Receiving Nodes: 
1 meter, 3 meters and 8.5 meters. 

For all experiments we measure the following performance metrics: 

Received Packets per Second: is the number of packets received in one second from a Receiving Node. This 
metric can be used (in combination to the payload size) to compute the effective throughput. 

Packet Loss: defines the percentage of packets which fail to reach the Receiving Node. 
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iSense / \ iSense 



Figure 2: The layout of the experiment. 

Received Signal Strength Indication (RSSI): RSSI is the relative received signal strength in a wireless envi- 
ronment, in arbitrary units. RSSI is an indication of the power level being received by the antenna. 
Therefore, the higher the RSSI number (or less negative in some devices), the stronger the signal. 

On each repetition, one of the 4 Transmitting Nodes was broadcasting 500 beacon messages with payload 
size varying from 6 to 96 bytes. Each Receiving Node was recording the RSSI and the received timestamp of 
each beacon as well as the total number of the received packets. Since the beacon was a broadcast packet, the 

4 Receiving Nodes were simultaneously receiving these beacons. Each one of the 4 Transmitting Nodes was 
placed at 3 different distances from the Receiving Nodes (i.e., 1, 3, 8.5 meters). After the measurements have 
been conducted the average values for 20 payload sizes for each distance have been calculated. 

5 Experimental Results 

Here we present the results of our experiment for the 3 different distances between the Transmitting and the 
Receiving Stations. 

5.1 Broadcasting Rate 

We start by measuring the broadcasting rate of the 4 different devices, for packets of different message sizes 
(i.e., message payload). We do this by continuously sending, from each of the Transmitting Nodes, 20 different 
payload sizes, ranging from 6 to 96 bytes. We calculate, for each device, the total period of time required to 
transmit 500 packets. We repeat the experiment 9 times to achieve good average results. The average results 
are illustrated in the figure [3j 

It should be mentioned that the XBee modules are connected with the Arduino using a serial UART interface 
which supports up to 115200 baud rate. But above the threshold of 38400 the communication between the 
Arduino and the XBee module becomes unstable in high transmission rates. In particular, when the received 
packets per second on XBee are above 150, Arduino continuously restarts. In our experiment the baud rate 
was set on 38400. 
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The device with the larger broadcasting rate is the iSense, while the SunSPOT and Arduino have the 
smaller broadcasting rate. The broadcasting rate on TelosB is almost double the rate on SunSPOT, because 
the Squawk Java Virtual Machine limits the performance of the SunSPOT. 

Broadcasting rate 

400 T 1 




H 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

6 8 10 12 14 16 20 24 28 32 40 48 56 64 68 72 76 80 88 96 

Payload 



Figure 3: Packets per Second on Broadcasting Nodes 
5.2 Received Packets per Second 

Each one of the 4 Transmitting Nodes was broadcasting 500 beacon messages with payload size varying from 
6 to 96 bytes. The received packets per second depend on the transmission rate of Transmitting Node. When 
the Transmitting Node is a SunsPOT or an Arduino, the received pps is almost the same for all Receiving 
Nodes and is equal with the transmission rate of SunSPOT and Arduino respectively. When TelosB is the 
Transmitting Node, the received pps is the same for all Receiving nodes, except from Arduino. The received 
pps on Arduino is decreasing for payload sizes over 28 bytes. 

In the following figure, the Received Packets per Second rates are illustrated, figure [4} The dist ance between 
the Transmitting and the Receiving Nodes on the left column, on the middle column and in the right column, 
is 1 meter, 3 meters and 8.5 meters respectively. 
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Figure 4: Packets per Second on Receiver 
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5.3 Packet loss rate 

The packet loss rate is larger while the distance is increasing. We also observe an increased packet loss rate, 
when the Transmitting Node has a broadcasting rate larger than the maximum receiving rate on the Receiving 
Node. 

In the following figure, the Packet loss rates are illustrated, figure [5} 
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Arduino Broadcaster 



ArduirK} Broadcaster 



Arduino Broadcaster 
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Figure 5: Packet Loss Rate 



payload 

8.5 meters 



Arduino has the larger packet loss rate, because of its limited receiving rate. Moreover, although the 
SunSPOT has also a limited receiving rate, the packet loss is smaller. This is due to internal Buffers on the 
SunSPOT's JVM, temporary store the received messages, avoiding delivery failures. 

An interesting fact is observed, when the distance between Receiving and Transmitting Nodes is 8.5 meters 
and the Transmitting Node is an iSense. Beside the receiving iSense, the rest of the Receiving Devices, have 
packet loss rate 100%. iSense is the only device with 0% packet loss, regardless of the broadcasting device, the 
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distance and the packet size. 



5.4 RSSI 

RSSI values depend on the modulation format. Despite the fact that, all devices use the same modulation 
format (i.e., offset quadrature phase-shift keying (OQPSK) ), the RSSI values present great deviation on 
identical signals; that is the same transmitted signal, simultaneously received from all Receiving Nodes. This 
phenomenon is also observed on SunSPOT and TelosB, despite the fact that both nodes utilize the same 
CC2420 transceiver. 

The RSSI.RSSLVAL register on CC2420 [H] chip, stores a digital 8 bit, signed 2's complement value. 
The RSSI value is always averaged over 8 symbol periods (128 //s), as defined in 802.15.4 standard. The 
RSSI.RSSLVAL value can be referred to the power P using the following equations: 

P = RSSI.VAL + RSSI.OFFSET[dBm], where the RSSLOFFSET is found empirically during system 
development. 

RSSLOFFSET is approximately -45. E.g., if reading a value of -50 from the RSSLVAL register, the RSSI value 
is approximately -5. 

The problem appears in the function which returns the value of the RSSI from a received packet, on TelosB. 
The specific function omits the RSSLOFFSET and returns the raw RSSLVAL. Moreover, the function does 
not apply the 2's complement and as a result returns a wrong RSSI value. On the other hand, SunSPOT 
implementation follows exactly the above specifications. 

In the following figure, the RSSI values are illustrated, figure [6j 
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Figure 6: RSSI values 
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6 Conclusions 

Studying the results presented above we conclude that the sensor node with the larger broadcasting and 
receiving rate is the iSense. iSense is the only device with 0% packet loss, regardless of the broadcasting device, 
the distance and the packet size. 

In contrast to iSense, Arduino is the only device with packet loss over 50% in large distances, with packet 
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size over 50 bytes. Moreover the broadcasting and receiving rate on Arduino, is very limited. This might be 
explained by the fact that Arduino and the XBee module are connected via the UART interface, in contrast 
to iSense, TelosB and SunSPOT in which the radio module is connected to the core sensor module via the SPI 
interface. 

The rate of broadcasting on SunSPOT is constant. SunSPOT is running the Squawk Java Virtual Machine, 
which limits the performance of the device. The overhead on the specific device is on the construction and the 
destruction of "Datagram Java objects" to 802.15.4 frames and vise versa and is confirmed by the fact that 
TelosB, with the same radio transceiver (CC2420), achieves much higher transmission rates. 

Regarding the RSSI values on the Receiving Nodes, there is no clear conclusion as to the correlation of the 
specific values. Each of the 4 Receiving Nodes extract, totally different RSSI values from broadcasted packets 
on same distances. 

Our future work concerns the examination of the correlation between RSSI and LQI values in a Heteroge- 
neous Network. Also, we want to examine the performance of the XBee module when it is connected to PC 
via a Serial to USB regulator. Moreover, it would be interesting to study the behavior of various algorithms 
(neighbor discovery, routing, etc.) in such Heterogeneous Networks. 
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